ソフトウェアアーキテクチャの基礎輪読会 23章
日付：12/5
調査者：ichimura.icon
交渉とファシリテーション
アーキテクトは企業の政治的状況を理解して、切り抜けることを期待されている
アーキテクチャの検討はその特性上、議論が生まれるもの
異議が必然として生じる
議論から企業の政治的状況を切り抜けるため、交渉力とファシリテートのスキルは重要なスキル
状況の例：専門外の人と要件定義をする場面で、相手を不快にすることなく正しく導く
ビジネスステークホルダとの交渉
コストと時間の観点が交渉では重要な切り札
アーキテクトの議論でも、この観点に焦点が当たる
交渉では重要だが、この観点を早めに切り出してしまうと他の要素によってうまく進まなくなりがち
そうした要素を一通り合意に達した後で切り出して交渉する
システムの決定は、議論の焦点に関わる領域に絞る
他のアーキテクトとの交渉
実証は議論に勝る
自分たちの特定の環境における議論は、googleの検索結果や経験ではなく実証によって証明する
意識
議論しすぎない
個人的なものにしすぎない
明確で簡潔な理由づけをする
ichimura.icon 本には勝てるという表現であるけれど、より正しい選択へも導けるはず
ichimura.icon もちろん上記は最終手段で、明確で簡潔な理由付けをより意識できるようになりたい
開発者との交渉
開発者を含めるチームからの信頼を得るために、アーキテクチャの要求は正当な根拠を以って説明する
要求の根拠を初めに説明する
一般に、同意できないことから入ると話を聞かなくなる
根拠を示すことで、開発者からの返答が反論から質問に変わる
開発者に自分たちで解決策を導き出してもらう
要求に反する意見を持っている場合、決定の根拠が満たされるのであればOKと伝える
ichimura.icon さらに、「他アーキテクトとの交渉」の内容も通じますよね
リーダーとしてのソフトウェアアーキテクト
アーキテクチャの4つのC
不用意に複雑なシステムになること（偶発的な複雑さ）を回避するための4つのC。
コミュニケーション(Communication)
協調性(Collaboration)
明瞭さ(Clarity)
簡潔さ(Conciseness)
プラグマティックでありながらもビジョナリーであること
上記を満たすバランスが大事
現実的なソリューションで考慮するべき要素や制約
予算とコスト
時間
チームのスキル
アーキテクチャ決定に関連するトレードオフと意味合い
提案されたーアーキテクチャ設計やソリューションの技術的な制限事項
現実的に考える要素や制約
企業、チーム内の技術スタック
トレードオフの理解
実現度
手本を示してチームをリードする
肩書にはついてこない。ピープルスキルが重要
ichimura.icon この著者、相当肩書だけのアーキテクトにヘイトむけてる気がする
問題解決は検討を促す質問で返すことで協調的に進められる
会話や交渉で頻繁に名前を呼ぶことで親近感を持てる
久しぶりの人、初めて会った人には目を合わせたり握手をしよう
相手がやりたがらない要求は、助けを求めるようにお願いする
名前をしっかり言うのがポイント
ichimura.icon 強すぎるんで、悪用厳禁だと思う
開発者から相談されるような存在を目指す
開発チームに溶け込む
アーキテクトはミーティングが多くなりがちだが、開発チームのために時間を確保することが重要
招待されるミーティングには、その理由を確認する
情報を把握するためだけであれば議事録を確認すればいい
招待者にアジェンダを委ねる
本当は必要ないかもしれない
関連する議論にだけ参加する
開発者が招待されるミーティングに参加する
開発チームの生産性を確保する
アーキテクトから招待するミーティングも最小限に止める
ミーティング = 仕事から引き剥がす
招集は朝一番、昼食後すぐ、1日の終わりのどこかで行う
開発チームといる時間を増やす
チームの一員であると言うメッセージを送り、信頼を得ることができる
ずっと居れなくても、赴いて歩き回って問題解決や質問、コーチングやメンタリングを行う
質疑応答